Software Vault: The Diamond Collection/The Diamond Collection (Software Vault)(Digital Impact).ISO/cdr15/isinfo.zip/ISPOLICY.001

Text File | 1995-01-01 | 61KB | 1,175 lines

█   ▀█▄   ▀▄ █▀▀▄▀▀█ ▄▀█▀▀▀▀ ▀█▀▀▄   ▄▀▀▀▄ ▀█▀▀▄   ▄▀▀▀▄ ▀█▀▀▄  █▀▀▄▀▀█  ▄▀▀▀▄
 █   █ █   █    █      █      █   █ █       █   █ █    █  █   █    █    █
 █   █  █  █    █     ▄█▄▄   ▀█▀█▀   ▀▀▄▄  ▀█▀▀▀  █    █ ▀█▀█▀     █     ▀▀▄▄
 █   █   █ █    █    ▀ █      █  ▀▄      █  █     █    █  █  ▀▄    █         █
 ▀▄ ▄▀   ▀▄▀   ▄█▄    ▄▀▄▄▄▄ ▀    ▀ ▀▄▄▄▄▀ ▀      ▀▄▄▄▄▀ ▀    ▀   ▄█▄   ▀▄▄▄▄▀

                            Echomail Network Policy

Version: 1.0
Updated: 01 January, 1995

─────────────────────────────] Contents of Policy [────────────────────────────
(Description)                                                      (Section)

Overview ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 1-0
Language ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 1-0-1
Introduction ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 1-1
Organization ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 1-2
Individual Systems and System Operators ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 1-2-1
Users ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 1-2-1-1
Points ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 1-2-1-2
Networks and Network Coordinators ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 1-2-2
Network Routing Hubs ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 1-2-2-1
Regions and Regional Coordinators ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 1-2-3
Zones and Zone Coordinators ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 1-2-4
International Coordinator ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 1-2-5
Top-down Organization, Checks and Balances ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 1-2-6
Definitions ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 1-3
Geography ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 1-3-1
Zone Mail Hour ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 1-3-2
Nodelist ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 1-3-3
Excessively Annoying Behavior ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 1-3-4
Commercial Use ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 1-3-5
Sysop Procedures ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 2-0
General ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 2-1
The Basics ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 2-1-1
Familiarity with Policy ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 2-1-2
Responsible for Traffic Entering the Network ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 2-1-3
Encryption and Review of Mail ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 2-1-4
No Alteration of Routed Mail ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 2-1-5
Private Netmail ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 2-1-6
No Disclosure of in-transit mail ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 2-1-6-1
Private mail addressed to you ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 2-1-6-2
Not Routing Mail ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 2-1-7
Exclusivity of Zone Mail Hour ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 2-1-8
Private Nodes ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 2-1-9
Observing Mail Events ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 2-1-10
Use of Current Nodelist ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 2-1-11
Excommunication (Expulsion) ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 2-1-12
Timing of Zone Mail Hour ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 2-1-13
Non-observance of Daylight Savings Time ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 2-1-14
How to obtain a node number ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 2-2
If You are Going Down ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 2-3
General Procedures for All Coordinators ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 3-0
Make Available Nodelists and Policies ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 3-1
Processing Nodelists and Distributing ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 3-2
Ensure the Latest Policy is Available ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 3-3
Be a Member of the Area Administered ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 3-4
Encourage New Sysops to Enter InterSports ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 3-5
Tradition and Precedent ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 3-6
Technical Management ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 3-7
Network Coordinator Procedures ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 4-0
Responsibilities ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 4-1
Routing Inbound Mail ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 4-2
Assigning Node Numbers ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 4-3
Maintaining the Nodelist ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 4-4
Making Available Policies and Nodelists ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 4-5
Regional Coordinator Procedures ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 5-0
Responsibilities ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 5-1
Assigning Node Numbers ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 5-2
Encouraging the Formation and Growth of Networks ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 5-3
Geographic Exemptions ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 5-4
Overseeing Network Operations ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 5-5
Making Available Nodelists and Policies ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 5-6
Zone Coordinator Procedures ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 6-0
General ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 6-1
International Coordinator Procedures ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 7-0
General ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 7-1
Selection ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 7-2
Resolution of Disputes ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 8-0
General ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 8-1
Problems with Another Sysop ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 8-2
Problems with your Network Coordinator ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 8-3
Problems with Other Coordinators ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 8-4
Appeal Process ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 8-5
Statute of Limitations ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 8-6
Right to a Speedy Decision ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 8-7
Return to Original Network ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 8-8
Echomail ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 8-9
Case Histories ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 8-10
Appendices ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 9-0
Timing of Zone Mail Hour ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 9-1
Contacts ∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙∙ 9-2
Acknowledgements ................................................... 9-3


─] Overview [──────────────────────────────────────────────────────────(1-0)─

This document establishes the policy for sysops who are members of the
InterSports echomail network.  InterSports is defined by a NodeList issued
weekly by the Nodelist Coordinator (NLC).


─] Language [────────────────────────────────────────────────────────(1-0-1)-

The official language of InterSports is English.  All documents must exist in
English.  Translation into other languages is encouraged.


─] Introduction [──────────────────────────────────────────────────────(1-1)-

InterSports is an amateur electronic mail system.  As such, all of its partici-
pants and operators are unpaid volunteers.  From its early beginning as a few
friends swapping messages back and forth (1991), it now (1994) includes over
150 systems on two continents.

InterSports is not a common carrier or a value-added service network and is a
public network only in as much as the independent, constituent nodes may
individually provide public access to the network on their system.

InterSports is large enough that it would quickly fall apart of its own weight
unless some sort of structure and control were imposed on it.  Multinet
operation provides the structure. Decentralized management provides the
control.  This document describes the procedures which have been developed to
manage the network.


─] Organization [──────────────────────────────────────────────────────(1-2)-

InterSports systems are grouped on several levels, and administration is decen-
tralized to correspond with these groupings.  This overview provides a
summary of the structure; specific duties of the coordinator positions are
given later in the document.

─] Individual Systems and Operators [────────────────────────────────(1-2-1)-

The smallest subdivision of InterSports is the individual system, corresponding
to a single entry in the nodelist.  The system operator (sysop) formulates a
policy for running the board and dealing with users.  The sysop must mesh
with the rest of the InterSports system to send and receive mail, and the local
policy must be consistent with other levels of InterSports.

─] Users [────────────────────────────────────────────────────────-(1-2-1-1)-

The sysop is responsible for the actions of any user when they affect the
rest of InterSports.  (If a user is annoying, the sysop is annoying.)  Any
traffic entering InterSports via a given node, if not from the sysop, is consid-
ered to be from a user and is the responsibility of the sysop.  (See section
2.1.3.)

─] Points [────────────────────────────────────────────────────────(1-2-1-2)-

A point is a "FidoNet"-compatible system that is not in the nodelist, but
communicates with InterSports through a node referred to as a bossnode.  A point
is generally regarded in the same manner as a user, for example, the bossnode
is responsible for mail from the point.  (See section 2.1.3.)  Points are
addressed by using the bossnode's nodelist address; for example, a point
system with a bossnode of 540/414 might be known as 540/414.1.  Mail destined
for the point is sent to the bossnode, which then routes it to the point.

In supporting points, the bossnode makes use of a private net number which
should not be generally visible outside of the bossnode-point relationship.
Unfortunately, should the point call another system directly (to do a file
request, for example), the private network number will appear as the caller's
address.  In this way, points are different from users, since they operate
"FidoNet"-compatible mailers which are capable of contacting systems other than
the bossnode.

─] Networks and Network Coordinators [──────────────────────────────-(1-2-2)-

A network is a collection of nodes in a local geographic area, usually
defined by an area of convenient telephone calling.  Networks coordinate
their mail activity to decrease cost.

The Network Coordinator is responsible for maintaining the list of nodes for
the network, and for forwarding netmail sent to members of the network from
other InterSports nodes.

The Network Coordinator is appointed by the Zone Coordinator.

─] Network Routing Hubs [──────────────────────────────────────────(1-2-2-1)-

Network Routing Hubs exist only in some networks.  They may be appointed by
the Network Coordinator, in order to assist in the management of a large net-
work.  The exact duties and procedures are a matter for the Network Coordina-
tor and the hubs to arrange, and will not be discussed here, except that a
network coordinator cannot delegate responsibility to mediate disputes.

─] Regions and Regional Coordinators [──────────────────────────────-(1-2-3)-

A region is a well-defined geographic area containing nodes which may or may
not be combined into networks.  A typical region will contain many nodes in
networks, and a few independent nodes which are not a part of any network.

The Regional Coordinator maintains the list of independent nodes in the
region and accepts nodelists from the Network Coordinators in the region.
These are compiled to create a regional nodelist, which is then sent to the
Zone Coordinator.  A Regional Coordinator does not perform message-forwarding
services for any nodes in the region.

Regional Coordinators are appointed by the Zone Coordinator.

─] Zones and Zone Coordinators [────────────────────────────────────-(1-2-4)-

A zone is a large geographic area containing many regions, covering one or
more countries and/or continents.

The Zone Coordinator compiles the nodelists from all of the regions in the
zone, and creates the master nodelist, which is then distributed over
InterSports in the zone.

Zone Coordinators are selected by the International Coordinator.

─] International Coordinator [──────────────────────────────────────-(1-2-5)-

The International Coordinator is the "first among equals" Zone Coordinator,
and coordinates the joint production of the master nodelist by the Zone
Coordinators.

The International Coordinator is selected by the Zone Coordinators.

─] Top Down Organization, Checks and Balances [──────────────────────(1-2-6)-

These levels act to distribute the administration and control of InterSports to
the lowest possible level, while still allowing for coordinated action over
the entire mail system.  Administration is made possible by operating in a
top-down manner.  That is, a person at any given level is responsible to the
level above, and responsible for the level below.

For example, a Regional Coordinator is responsible to the Zone Coordinator
for anything that happens in the region.  From the point of view of the Zone
Coordinator, the Regional Coordinator is completely responsible for the
smooth operation of the region.  Likewise, from the point of view of the
Regional Coordinator, the Network Coordinator is completely responsible for
the smooth operation of the network.

If a person at any level above sysop is unable to properly perform their
duties, the Zone Coordinator can replace him.


─] Definitions [──────────────────────────────────────────────────────-(1-3)-

─] Geography [──────────────────────────────────────────────────────-(1-3-1)-

Each level of InterSports is geographically contained by the level immediately
above it.  A given geographic location is covered by one zone and one region
within that zone, and is either in one network or not in a network.  There
are never two zones, two regions, or two networks which cover the same
geographic area.

If a node is in the area of a network, it should be listed in that network,
not as an independent in the region.  (The primary exception to this is a
node receiving inordinate amounts of host-routed mail; see section 4.2).
Network boundaries are based on calling areas as defined by the local
telephone company.  Even in the case of areas where node density is so great
that more than one network is needed to serve one local calling area, a geo-
graphic guideline is used to decide which nodes belong to what network.
Network membership is based on geographic or other purely technical ratio-
nale.  It is not based on personal or social factors.

There are cases in which the local calling areas lead to situations where
logic dictates that a node physically in one InterSports Region should be
assigned to another.  In those cases, with the agreement of the Regional
Coordinators and Zone Coordinator involved, exemptions may be granted.  Such
exemptions are described in section 5.6.

─] Zone Mail Hour [──────────────────────────────────────────────────(1-3-2)-

Zone Mail Hour (ZMH) is a defined time during which all nodes in a zone are
required to be able to accept netmail.  Each InterSports zone defines a ZMH and
publishes the time of its ZMH to all other InterSports zones.  See sections
2.1.8 and 10.2.

Zone Mail Hour has previously been referred to as National Mail Hour and
Network Mail hour.  The term Zone Mail Hour is more accurate.

─] Nodelist [────────────────────────────────────────────────────────(1-3-3)-

The nodelist is a file updated weekly which contains the addresses of all
recognized InterSports nodes.  This file is currently made available by the
Nodelist Coordinator not later than Zone Mail Hour each Friday, and is available
electronically for download or file request at no charge.  To be included in
the nodelist, a system must meet the requirements defined by this document.
No other requirements may be imposed.

─] Excessively Annoying Behavior [──────────────────────────────────-(1-3-4)-

There are references throughout this policy to "excessively annoying behav-
ior", especially in section 9 (Resolution of Disputes).  It is difficult to
define this term, as it is based upon the judgement of the coordinator
structure.  Generally speaking, annoying behavior irritates, bothers, or
causes harm to some other person.  It is not necessary to break a law to be
annoying.

There is a distinction between excessively annoying behavior and (simply)
annoying behavior.  For example, there is a learning curve that each new
sysop must climb, both in the technical issues of how to set up the software
and the social issues of how to interact with InterSports.  It is a rare sysop
who, at some point in this journey, does not manage to annoy others.  Only
when such behavior persists, after being pointed out to the sysop, does it
becomes excessively annoying.  This does not imply that it is not possible to
be excessively annoying without repetition (for example, deliberate falsifi-
cation of mail would likely be excessively annoying on the very first try),
but simply illustrates that a certain amount of tolerance is extended.

Refer to section 9 and the case studies (section 10.3) for more information.

─] Commercial Use [──────────────────────────────────────────────────(1-3-5)-

InterSports is an amateur network.  Participants spend their own time and money
to make it work for the good of all the users.  It is not appropriate for a
commercial enterprise to take advantage of these volunteer efforts to further
their own business interests.  On the other  hand, InterSports provides a
convenient and effective means for companies and users to exchange informa-
tion, to the mutual benefit of all.

Network Coordinators could be forced to subsidize commercial operations by
forwarding host-routed netmail, and could even find themselves involved in a
lawsuit if any guarantee was suggested for mail delivery.   It is therefore
InterSports policy that commercial mail is not to be routed.  "Commercial mail"
includes mail which furthers specific business interests without being of
benefit to the net as a whole.  Examples include company-internal mail,
inter-corporate mail, specific product inquiries (price quotes, for in-
stance), orders and their follow-ups, and  all other subjects specifically
related to business.


─] SysOp Procedures [──────────────────────────────────────────────────(2-0)-

─] General [──────────────────────────────────────────────────────────-(2-1)-

─] The Basics [──────────────────────────────────────────────────────(2-1-1)-

As the sysop of an individual node, you can generally do as you please, as
long as you observe mail events, are not excessively annoying to other nodes
in InterSports, and do not promote or participate in the distribution of pirated
copyrighted software or other illegal behavior via InterSports.


─] Familiarity with Policy [────────────────────────────────────────-(2-1-2)-

In order to understand the meaning of "excessively annoying", it is incumbent
upon all sysops to occasionally re-read InterSports policy.  New sysops must
familiarize themselves with policy before requesting a node number.


─] Responsibility for Traffic Entering the Network [────────────────-(2-1-3)-

The sysop listed in the nodelist entry is responsible for all traffic
entering InterSports via that system.  This includes (but is not limited to)
traffic entered by users, points, and any other networks for which the system
might act as a gateway.  If a sysop allows "outside" messages to enter
InterSports via the system, the gateway system must be clearly identified by
InterSports node number as the point of origin of that message, and it must act
as a gateway in the reverse direction.  Should such traffic result in a
violation of Policy, the sysop must rectify the situation.


─] Encryption and Review of Mail [──────────────────────────────────-(2-1-4)-

InterSports is an amateur system.  Our technology is such that the privacy of
messages cannot be guaranteed.  As a sysop, you have the right to review
traffic flowing through your system, if for no other reason than to ensure
that the system is not being used for illegal or commercial purposes.
Encryption obviously makes this review impossible.  Therefore, encrypted
and/or commercial traffic that is routed without the express permission of
all the links in the delivery system constitutes annoying behavior.  See
section 1.3.5 for a definition of commercial traffic.


─] No Alteration of Routed Mail [────────────────────────────────────(2-1-5)-

You may not modify, other than as required for routing or other technical
purposes, any message, netmail or echomail, passing through the system from
one InterSports node to another.  If you are offended by the content of a
message, the procedure described in section 2.1.7 must be used.


─] Private Netmail [────────────────────────────────────────────────-(2-1-6)-

The word "private" should be used with great care, especially with users of a
BBS.  Some countries have laws which deal with "private mail", and it should
be made clear that the word "private" does not imply that no person other
than the recipient can read messages.  Sysops who cannot provide this
distinction should consider not offering users the option of "private mail".

If a user sends a "private message", the user has no control over the number
of intermediate systems through which that message is routed.  A sysop who
sends a message to another sysop can control this aspect by sending the
message direct to the recipient's system, thus guaranteeing that only the
recipient or another individual to whom that sysop has given authorization
can read the message.  Thus, a sysop may have different expectations than a
casual user.

─] No Disclosure of In-transit Mail [──────────────────────────────(2-1-6-1)-

Disclosing or in any way using information contained in private netmail
traffic not addressed to you or written by you is considered annoying
behavior, unless the traffic has been released by the author or the recipient
as a part of a formal policy complaint.  This does not apply to echomail
which is by definition a broadcast medium, and where private mail is often
used to keep a sysop-only area restricted.

─] Private Mail addressed to you [────────────────────────────────-(2-1-6-2)-

The issue of private mail which is addressed to you is more difficult than
the in-transit question treated in the previous section.  A common legal
opinion holds that when you receive a message it becomes your property and
you have a legal right to do with it what you wish.  Your legal right does
not excuse you from annoying others.

In general, sensitive material should not be sent using InterSports.  This ideal
is often compromised, as InterSports is our primary mode of communication.  In
general, if the sender of a message specifically requests in the text of the
message that the contents be kept confidential, release of the message into a
public forum may be considered annoying.

There are exceptions.  If someone is saying one thing in public and saying
the opposite in private mail, the recipient of the private mail should not be
subjected to harassment simply because the sender requests that the message
not be released.  Judgement and common sense should be used in this area as
in all other aspects of InterSports behavior.

─] Not Routing Mail [────────────────────────────────────────────────(2-1-7)-

You are not required to route traffic if you have not agreed to do so.  You
are not obligated to route traffic for all if you route it for any, unless
you hold a Network Coordinator or Hub Coordinator position.  Routing traffic
through a node not obligated to perform routing without the permission of
that node may be annoying behavior.  This includes unsolicited echomail.

If you do not forward a message when you previously agreed to perform such
routing, the message must be returned to the sysop of the node at which it
entered InterSports with an explanation of why it was not forwarded.  (It is not
necessary to return messages which are addressed to a node which is not in
the current nodelist.)  Intentionally stopping an in-transit message without
following this procedure constitutes annoying behavior.  In the case of a
failure to forward traffic due to a technical problem, it does not become
annoying unless it persists after being pointed out to the sysop.


─] Exclusitivty of Zone Mail Hour [──────────────────────────────────(2-1-8)-

Zone Mail Hour is the heart of InterSports, as this is when network mail is
passed between systems.  Any system which wishes to be a part of InterSports
must be able to receive mail during this time using the protocol defined in the
current "FidoNet" Technical Standards Committee publication (FTS-0001 at this
writing).  It is permissible to have greater capability (for example, to
support additional protocols or extended mail hours), but the minimum
requirement is FTS-0001 capability during this one hour of the day.

This time is exclusively reserved for netmail.  Many phone systems charge on
a per-call basis, regardless of whether a connect, no connect, or busy signal
is encountered.  For this reason, any activity other than normal network mail
processing that ties up a system during ZMH is considered annoying behavior.
Echomail should not be transferred during ZMH.  User (BBS) access to a system
is prohibited during ZMH.

A system which is a member of a local network may also be required to observe
additional mail events, as defined by the Network Coordinator.  Access
restrictions during local network periods are left to the discretion of the
Network Coordinator.


─] Private Nodes [──────────────────────────────────────────────────-(2-1-9)-

The rare exception to ZMH compliance is private nodes.  Persons requesting
private nodes should be supported as points if possible.  A private listing
is justified when the system must interface with many others, such as an
echomail distributor.  In these cases, the exact manner and timing of mail
delivery is arranged between the private node and other systems.  Such an
agreement between a private system and a hub is not binding on any replace-
ment for that hub.  A private node must be a part of a network (they cannot
be independents in the region.)

Private listings impact each member of InterSports, since they take up space in
everyone's nodelist.  Private listings which are for the convenience of one
sysop (at the expense of every other sysop in InterSports) are a luxury which is
no longer possible.  Non-essential redundant listings (more than one listing
for the same telephone number, except as mandated by FTSC standards) also
fall into this category.  Sysops requesting private or redundant listings
must justify them with a statement explaining how they benefit the local net
or InterSports as a whole.  The Network Coordinator or Regional Coordinator may
review this statement at any time and listings which are not justified will
be removed.


─] Observing Mail Events [──────────────────────────────────────────(2-1-10)-

Failure to observe the proper mail events is grounds for any node to be
dropped from InterSports without notice (since notice is generally given by
netmail).


─] Use of Current Nodelists [──────────────────────────────────────-(2-1-11)-

Network mail systems generally operate unattended, and place calls at odd
hours of the night.  If a system tries to call an incorrect or out-of-date
number, it could cause some poor citizen's phone to ring in the wee hours of
the morning, much to the annoyance of innocent bystanders and civil authori-
ties.  For this reason, a sysop who sends mail is obligated to obtain and use
the most recent edition of the nodelist as is practical.


─] Excommunication (Expulsion) [────────────────────────────────────(2-1-12)-

A system which has been dropped from the network is said to be excommunicated
(i.e. denied communication).  If you find that you have been excommunicated
without warning, your coordinator was unable to contact you.  You should
rectify the problem and contact your coordinator.

Systems may also be dropped from the nodelist for cause.  See section 9, and
sections 4.3 and 5.2.

It is considered annoying behavior to assist a system which was excommuni-
cated in circumventing that removal from the nodelist.  For example, if you
decide to provide an echomail feed to your friend who has been excommuni-
cated, it is likely that your listing will also be removed.


─] Timing of Zone Mail Hour [──────────────────────────────────────-(2-1-13)-

The exact timing of Zone Mail Hour for each zone is set by the Zone Coordina-
tor.  See section 10.2.


─] Non-observance of Daylight Savings Time [────────────────────────(2-1-14)-

InterSports does not observe daylight savings time.  In areas which observe
daylight savings time the InterSports mail schedules must be adjusted in the
same direction as the clock change.  Alternatively, you can simply leave your
system on standard time.


─] How to Obtain a Node Number [──────────────────────────────────────-(2-2)-


You must first obtain a current nodelist so that you can send mail.  You do
not need a node number to send mail, but you must have one in order for
others to send mail to you.

The first step in obtaining a current nodelist is to locate a InterSports
bulletin board.  Most bulletin board lists include at least a few InterSports
systems, and usually identify them as such.  Use a local source to obtain
documents because many networks have detailed information available which
explains the coverage area of the network and any special requirements or
procedures.

Once you have a nodelist, you must determine which network or region covers
your area.  Regions are numbered 1-99; network numbers are greater than 99.
Networks are more restricted in area than regions, but are preferred since
they improve the flow of mail and provide more services to their members.  If
you cannot find a network which covers your area, then pick the region which
does.

Once you have located the network or region in your area, send a message
containing a request for a node number to node zero of that network or
region.  The request must be sent by netmail, as this indicates that your
system has InterSports capability.

You must set up your software so that the from-address in your message does
not cause problems for the coordinator who receives it.  If you pick the
address of an existing system, this will cause obvious problems.  If your
software is capable of using address -1/-1, this is the traditional address
used by potential sysops.  Otherwise use net/9999 (e.g. if you are applying
to net 123, set your system up as 123/9999).  Many nets have specific
instructions available to potential sysops and these procedures may indicate
a preference for the from-address.

The message you send must include at least the following information:

     1) Your name.
     2) Your voice telephone number
     3) The name of your system.
     4) The city and state where your system is located.
     5) The phone number to be used when calling your system.
     6) Your hours of operation, netmail and BBS.
     7) The maximum baud rate you can support.
     8) The type of mailer software and modem you are using.

Your coordinator may contact you for additional information.  All information
submitted will be kept confidential and will not be supplied to anyone except
the person who assumes the coordinator position at the resignation of the
current coordinator.

You must indicate that you have read, and agree to abide by, this document
and all the current policies of InterSports.

Please allow at least two weeks for a node number request to be processed.
If you send your request to a Regional Coordinator, it may forwarded to the
appropriate Network Coordinator.


─] If you are going down [────────────────────────────────────────────-(2-3)-

If your node will be down for an extended period (more than a day or two),
inform your coordinator as soon as possible.  It is not your coordinator's
responsibility to chase you down for a status report, and if your system
stops accepting mail it will be removed from the nodelist.

Never put an answering machine or any other device which answers the phone on
your phone line while you are down.  If you do, calling systems will get the
machine repeatedly, racking up large phone bills, which is very annoying.  In
short, the only thing which should ever answer the telephone during periods
when the nodelist indicates that your node will accept mail is InterSports-
compatible software which accepts mail.

If you will be leaving your system unattended for an extended period of time
(such as while you are on vacation), you should notify your coordinator.
Systems have a tendency to "crash" now and then, so you will probably want
your coordinator to know that it is a temporary condition if it happens while
you are away.


─] General Procedures for All Coordinators [──────────────────────────-(3-0)-

─] Make Available Nodelists, and Policies [────────────────────────────(3-1)-

Any Coordinator is responsible for obtaining and making available, on a
weekly basis, nodelist files and policies.


─] Processing Nodelists, and Distributing [────────────────────────────(3-2)-

Each coordinator is responsible for obtaining nodelist information from the
level below, processing it, and passing the results to the level above.  The
timing of this process is determined by the requirements imposed by the level
above.


─] Ensure the Latest Policies are Available [──────────────────────────(3-3)-

A Coordinator is responsible to make the current version of this document
available to the level below, and to encourage familiarity with it.

In addition, a coordinator is required to forward any local policies received
to the level above, and to review such policies.  Although not required,
common courtesy dictates that when formulating a local policy, the participa-
tion of the level above should be solicited.


─] Be a Member of the Area Administered [──────────────────────────────-(3-4)-

A coordinator must be a member of the area administered. That is, a Network
Coordinator must be a member of that network by virtue of geography.  A
Regional Coordinator must be either a member of a network in the region, or
an independent in the region.


─] Encourage New SysOps to Enter InterSports [────────────────────────-(3-5)-

A coordinator is encouraged to operate a public bulletin board system which
is freely available for the purpose of distributing Policy, and Nodelists to
potential new sysops.  Dissemination of this information to persons who are
potential InterSports sysops is important to the growth of InterSports, and
coordinators should encourage development of new systems.


─] Tradition and Precedent [──────────────────────────────────────────-(3-6)-

A coordinator is not bound by the practices of predecessor or peers beyond
the scope of this document.

In addition, a new coordinator has the right to review any decision made by
predecessors for compliance with Policy, and take whatever actions may be
necessary to rectify any situations not in compliance.


─] Technical Management [──────────────────────────────────────────────(3-7)-

The primary responsibility of any coordinator is technical management of
network operations.  Decisions must be made on technical grounds.



─] Network Coordinator Procedures [────────────────────────────────────(4-0)-

─] Responsibilities [──────────────────────────────────────────────────(4-1)-

A Network Coordinator has the following responsibilities:

   1) To receive incoming mail for nodes in the network, and arrange
   delivery to its recipients.

   2) To assign node numbers to nodes in the network.

   3) To maintain the nodelist for the network, and to send a copy of it to
   the Regional Coordinator whenever it changes.

   4) To make available to nodes in the network new nodelist difference
   files, and new revisions of Network Policy Documents as they are received,
   and to periodically check to insure that nodes use up to date nodelists.


─] Routing Inbound Mail [──────────────────────────────────────────────(4-2)-

It is your responsibility as Network Coordinator to coordinate the receipt
and forwarding of host-routed inbound netmail for nodes in your network.  The
best way to accomplish this is left to your discretion.

If a node in your network is receiving large volumes of mail you can request
that the sysop contact the systems which are sending this mail and request
that they not host-route it.  If the problem persists, you can request your
Regional Coordinator to assign the node a number as an independent and drop
the system from your network.

Occasionally a node will make a "bombing run" (sending one message to a great
many nodes).  If a node in another network is making bombing runs on your
nodes and routing them through your inbound host, then you can complain to
the network coordinator of the offending node.  (If the node is an indepen-
dent, complain to the regional coordinator.)  Bombing runs are considered to
be annoying.

Another source of routing overload is echomail.  Echomail cannot be allowed
to degrade the ability of InterSports to handle normal message traffic.  If a
node in your network is routing large volumes of echomail, you can ask the
sysop to either limit the amount of echomail or to stop routing echomail.

You are not required to forward encrypted, commercial, or illegal mail.
However, you must follow the procedures described in section 2.1.7 if you do
not forward the mail.


─] Assigning Node Numbers [────────────────────────────────────────────(4-3)-

It is your responsibility to assign node numbers to new nodes in your net-
work.  You may also change the numbers of existing nodes in your network,
though you should check with your member nodes before doing so.  You may
assign any numbers you wish, so long as each node has a unique number within
your network.

You must not assign a node number to any system until you have received a
formal request from that system by InterSports mail.  This will ensure that the
system is minimally operational.  The strict maintenance of this policy has
been one of the great strengths of InterSports.

It is also recommended, though not required, that you call a board which is
applying for a node number before assigning it a node number.

You may not assign a node number to a node in an area covered by an existing
network.  Further, if you have nodes in an area covered by a network in
formation, those nodes must be transferred to the new network.

You should use network mail to inform a new sysop of the node number, as this
helps to insure that the system is capable of receiving network mail.

If a node in your network is acting in a sufficiently annoying manner, then
you can take whatever action you deem fit, according to the circumstances of
the case.


─] Maintaining the Nodelist [──────────────────────────────────────────(4-4)-


You should implement name changes, phone number changes, and so forth in your
segment of the nodelist as soon as possible after the information is received
from the affected node.  You should also on occasion send a message to every
node in your network to ensure that they are operational.  If a node turns
out to be "off the air" with no prior warning, you can either mark the node
down or remove it from the nodelist.  (Nodes are to be marked DOWN for a
maximum of two weeks, after which the line should be removed from the node-
list.)

At your discretion, you may distribute a portion of this workload to routing
hubs.  In this case, you should receive the nodelists from the Hub Coordina-
tors within your network.  You will need to maintain a set of nodelists for
each hub within your network, since you cannot count on getting an update
from each Hub Coordinator every week.  You should assemble a master nodelist
for your network every week and send it to your Regional Coordinator by the
day and time designated.  It is suggested that you do this as late as is
practical, so as to accommodate any late changes, balanced with the risk of
missing the connection with your Regional Coordinator and thus losing a week.

─] Making Available Policies and Nodelists [──────────────────────────-(4-5)-

As a Network Coordinator you should obtain a new nodelist from the Nodelist
Coordinator.  The nodelist is currently made available each Friday, and you must
make these files available to all nodes in the network, and you are encouraged
to make them available to the general public for download.

You should also obtain the most recent versions of the Policy documents that
bind the members of your network, and make those available to the nodes in
your network.  Policies are released at sporadic intervals, so you should
also inform the nodes in your network when such events occur, and ensure the
nodes are generally familiar with the changes.

Policy and the nodelist are the glue that holds us together.
Without them, we would cease to be a community, and become just another
random collection of bulletin boards.



─] Regional Coordinator Procedures [──────────────────────────────────-(5-0)-

─] Responsibilities [──────────────────────────────────────────────────(5-1)-

A Regional Coordinator has the following responsibilities:

   1) To assign node numbers to independent nodes in the region.

   2) To encourage independent nodes in the region to join existing net-
   works, or to form new networks.

   3) To assign network numbers to networks in the region and define their
   boundaries.

   4) To compile a nodelist of all of the networks and independents in the
   region, and to send a copy of it to the Zone Coordinator whenever it
   changes.

   5) To ensure the smooth operation of networks within the region.

   6) To make new nodelist difference files, Policies, and issues of
   FidoNews available to the Network Coordinators in the region as soon as
   is practical.


─] Assigning Node Numbers [────────────────────────────────────────────(5-2)-

It is your responsibility to assign node numbers to independent nodes in your
region. You may also change the numbers of existing nodes in your region,
though you should check with the respective nodes before doing so.  You may
assign any numbers you wish, so long as each node has a unique number within
your region.

You should not assign a node number to any system until you have received a
formal request from that system by InterSports mail.  This will ensure that the
system is minimally operational.  The strict maintenance of this policy has
been one of the great strengths of InterSports.

It is also recommended, though not required, that you call a board which is
applying for a node number before assigning it a node number.

You should use network mail to inform a new sysop of the node number, as this
helps to insure that the system is capable of receiving network mail.

If a node in your region is acting in a sufficiently annoying manner, then
you can take whatever action you deem fit, according to the circumstances of
the case.

If you receive a node number request from outside your region, you must
forward it to the most local coordinator for the requester as you can deter-
mine.  If you receive a node number request from a new node that is in an
area covered by an existing network, then you must forward the request to the
Coordinator of that network instead of assigning a number yourself.

If a network forms in an area for which you have independent nodes, those
nodes will be transferred to the local network as soon as is practical.


─] Encouraging the Growth and Formation of Networks [──────────────────(5-3)-

One of your main duties as a Regional Coordinator is to promote the growth of
networks in your region.

You should avoid having independent nodes in your region which are within the
coverage area of a network.  There are, however, certain cases where a node
should not be a member of a network, such as a system with a large amount of
inbound netmail; see section 4.2.

If several independent nodes in your region are in a local area you should
encourage them to form a network, and if necessary you may require them to
form a network.  Refer to section 2.4.  Note that this is not intended to
encourage the formation of trivial networks.  Obviously, one node does not
make a network.  The exact number of nodes required for an effective network
must be judged according to the circumstances of the situation, and is left
to your discretion.


─] Geographic Exemptions [────────────────────────────────────────────-(5-4)-

There are cases where local calling geography does not follow InterSports re-
gions.  In exceptional cases, exemptions to normal geographic guidelines are
agreed upon by the Regional Coordinators and Zone Coordinator involved.  Such
an exemption is not a right, and is not permanent.  When a network is formed
in the proper region that would provide local calling access to the exempted
node, it is no longer exempt.  An exemption may be reviewed and revoked at
any time by any of the coordinators involved.


─] Overseeing Network Operations [────────────────────────────────────-(5-5)-

It is your responsibility as Regional Coordinator to ensure that the networks
within your region are operating in an acceptable manner.  This does not mean
that you are required to operate those networks; that is the responsibility
of the Network Coordinators.  It means that you are responsible for assuring
that the Network Coordinators within your region are acting responsibly.

If you find that a Network Coordinator within your region is not properly
performing the duties outlined in Section 4, you should take inform the Zone
Coordinator of the situation immediately so the situation can be fixed.


─] Making Available Nodelists and Policies [──────────────────────────-(5-6)-

As a Regional Coordinator, it is your responsibility to obtain the latest
nodelist and network policies, as they are published, and to make them available
to the Network Coordinators within your region.  The nodelist is posted weekly
on Friday by the Nodelist Coordinator.

It is your responsibility to make these available to all Network Coordinators
in your region as soon as is practical after you receive them.  The method of
distribution is left to your discretion.  You are not required to distribute
them to any independent nodes in your region, though you may if you wish.  You
are encouraged to make all these documents available for downloading by the
general public.



─] Zone Coordinators Procedures [──────────────────────────────────────(6-0)-

─] General [──────────────────────────────────────────────────────────-(6-1)-

A Zone Coordinator for InterSports has the primary task of maintaining the
nodelist for the Zone, sharing it with the other Zone Coordinators, and
ensuring the distribution of the master nodelist (or difference file) to the
Regions in the Zone.  The Zone Coordinator is also responsible for coordinat-
ing the distribution of Network Policy documents.

The Zone Coordinator is responsible for the maintenance of the nodelist for
the administrative region.  The Administrative Region has the same number as
the zone, and consists of nodes assigned for administrative purposes not
related to the sending and receiving of normal network mail.

A Zone Coordinator is charged with the task of ensuring the smooth operation
of the Zone, which is done by appointing and supervising the Regional Coordi-
nators.

If a Zone Coordinator determines that a Regional Coordinator is not properly
performing the duties outlined in section 5, a replacement should be found.

The Zone Coordinator defines the geographic boundaries of the regions within
the zone and sets the time for the Zone Mail Hour.

The Zone Coordinator is responsible for reviewing and approving any geograph-
ic exemptions as described in section 5.4.

The Zone Coordinator is responsible for insuring the smooth operation of
gates between that zone and all other zones for the transfer of interzonal
mail.

The Zone Coordinators are responsible for the selection of the International
Coordinator from among their ranks.


─] International Coordinator Procedures [──────────────────────────────(7-0)-

─] General [──────────────────────────────────────────────────────────-(7-1)-

The International Coordinator is the "first among equals" Zone Coordinator.

The International Coordinator has the primary task of coordinating the
creation of the master nodelist by managing the distribution between the
Zones of the Zone nodelists.  The International Coordinator is responsible
for definition of new zones and for negotiation of agreements for communica-
tion with other networks.  ("Other network" in this context means other
networks with which InterSports communicates as peer-to-peer, not "network" in
the sense of the InterSports organizational level.)


─] Selection [────────────────────────────────────────────────────────-(7-2)-

The International Coordinator is selected (or removed) by the Zone Coordinator.


─] Resolution of Disputes [────────────────────────────────────────────(8-0)-

─] General [──────────────────────────────────────────────────────────-(8-1)-

The InterSports judicial philosophy can be summed up in two rules:

     1) Thou shalt not excessively annoy others.

     2) Thou shalt not be too easily annoyed.

In other words, there are no hard and fast rules of conduct, but reasonably
polite behavior is expected.  Also, in any dispute both sides are examined,
and action could be taken against either or both parties. ("Judge not, lest
ye be judged!")

The coordinator structure has the responsibility for defining "excessively
annoying".  Like a common definition of pornography ("I can't define it, but
I know it when I see it."), a hard and fast definition of acceptable InterSports
behavior is not possible.  The guidelines in this policy are deliberately
vague to provide the freedom that the coordinator structure requires to
respond to the needs of a growing and changing community.

The first step in any dispute between sysops is for the sysops to attempt to
communicate directly, at least by netmail, preferably by voice.  Any com-
plaint made that has skipped this most basic communication step will be
rejected.

Filing a formal complaint is not an action which should be taken lightly.
Investigation and response to complaints requires time which coordinators
would prefer to spend doing more constructive activities.  Persons who
persist in filing trivial policy complaints may find themselves on the wrong
side of an excessively-annoying complaint.  Complaints must be accompanied
with verifiable evidence, generally copies of messages; a simple word-of-
mouth complaint will be dismissed out of hand.

Failure to follow the procedures herein described (in particular, by skipping
a coordinator, or involving a coordinator not in the appeal chain) is in and
of itself annoying behavior.


─] Problems with Another SysOp [──────────────────────────────────────-(8-2)-

If you are having problems with another sysop, you should first try to work
it out via netmail or voice conversation with the other sysop.

If this fails to resolve the problem, you should complain to your Network
Coordinator and the other sysop's Network Coordinator.  If one or both of you
is not in a network, then complain to the appropriate Regional Coordinator.
Should this fail to provide satisfaction, you have the right to follow the
appeal process described in section 8.5.


─] Problems with Your Network Coordinator [────────────────────────────(8-3)-

If you are having problems with your Network Coordinator and feel that you
are not being treated properly, you are entitled to a review of your situa-
tion.  As with all disputes, the first step is to communicate directly to
attempt to resolve the problem.

The next step is to contact your Zone Coordinator.  If your case has
merit, there are several possible courses of action, including a change of
Network Coordinators or even the disbanding of your network.  If you have
been excommunicated by your Network Coordinator, that judgement may be
reversed, at which point you will be reinstated into your net.

If you fail to obtain relief from your Regional Coordinator, you have the
right to follow the appeal process described in section 8.5.


─] Problems with Other Coordinators [──────────────────────────────────(8-4)-

Complaints concerning annoying behavior on the part of any coordinator are
treated as in section 8.2 and should be filed with the next level of coordi-
nator.  For example, if you feel that your Regional Coordinator is guilty of
annoying behavior (as opposed to a failure to perform duties as a coordina-
tor) you should file your complaint with the Zone Coordinator.

Complaints concerning the performance of a coordinator in carrying out the
duties mandated by policy are accepted only from the level immediately below.
For example, complaints concerning the performance of Regional Coordinators
would be accepted from Network Coordinators and independents in that region.
Such complaints should be addressed to the Zone Coordinator after an appro-
priate attempt to work them out by direct communications.


─] Appeal Process [────────────────────────────────────────────────────(8-5)-

A decision made by a coordinator may be appealed to the next level.  Appeals
must be made within two weeks of the decision which is being appealed.  All
appeals must follow the chain of command; if levels are skipped the appeal
will be dismissed out of hand.

An appeal will not result in a full investigation, but will be based upon the
documentation supplied by the parties at the lower level.  For example, an
appeal of a Network Coordinator's decision will be decided by the Regional
Coordinator based upon information provided by the coordinator and the sysop
involved; the Regional Coordinator is not expected to make an independent
attempt to gather information.

The appeal structure is as follows:

   Network Coordinator decisions may be appealed to the appropriate Region-
   al Coordinator.

   Regional Coordinator decisions may be appealed to the appropriate Zone
   Coordinator.  At this point, the Zone Coordinator will make a decision
   and communicate it to the Regional Coordinators in that zone.  This
   decision may be reversed by a majority vote of the Regional Coordina-
   tors.

   Zone Coordinator decisions may be appealed to the International Coordi-
   nator.  The International Coordinator will make a decision and communi-
   cate it to the Zone Coordinator.

If your problem is with a Zone Coordinator per se, that is, a Zone Coordina-
tor has committed a Policy violation against you, your complaint should be
filed with the International Coordinator, who will make a decision and submit
it to the Zone Coordinator.


─] Statute of Limitations [────────────────────────────────────────────(8-6)-

A complaint may not be filed more than 60 days after the date of discovery of
the source of the infraction, either by admission or technical evidence.
Complaints may not be filed more than 120 days after the incident unless they
involve explicitly illegal behavior.


─] Right to a Speedy Decision [────────────────────────────────────────(8-7)-

A coordinator is required to render a final decision and notify the parties
involved within 30 days of the receipt of the complaint or appeal.


─] Return to Original Network [────────────────────────────────────────(8-8)-

Once a policy dispute is resolved, any nodes reinstated on appeal are re-
turned to the local network or region to which they geographically or techni-
cally belong.


─] Echomail [──────────────────────────────────────────────────────────(8-9)-

Echomail is an important and powerful force in InterSports.  For the purposes of
Policy Disputes, echomail is simply a different flavor of netmail, and is
therefore covered by Policy.  By its nature, echomail places unique technical
and social demands on the net over and above those covered by this version of
Policy.  In recognition of this, an echomail policy which extends (and does
not contradict) general Policy, maintained by the Echomail Coordinators, and
ratified by a process similar to that of this document, is recognized by the
InterSports Coordinators as a valid structure for dispute resolution on matters
pertaining to echomail.  At some future date the echomail policy document may
be merged with this one.


─] Case Histories [──────────────────────────────────────────────────-(8-10)-

Most of InterSports Policy is interpretive in nature.  No one can see what is to
come in our rapidly changing environment.  Policy itself is only a part of
what is used as the ground rules for mediating disputes -- as or more impor-
tant are the precedents.

In order to accommodate this process, case histories may be added to or
removed from this document by the International Coordinator, with such a
revision subject to reversal by the Zone Coordinator Council.  Should Policy
be amended in such a way to invalidate a precedent, Policy supersedes said
precedent.  (A carefully prepared amendment would address this by removing
the precedent reference as a part of the amendment.)

Although a case may be removed, the text of a case history may not be modi-
fied by any mechanism.  Case history is written close to the time of the
decision, by those involved with it.  Amending the text of a case history is
the same as revising history, something quite inappropriate in an organiza-
tion dedicated to moving information.



─] Appendices [────────────────────────────────────────────────────────(9-0)-

─] Timing of Zone Mail Hours [────────────────────────────────────────-(9-1)-

Zone Mail Hour is observed each day, including weekends and holidays.  The
time is based upon Universal Coordinated Time (UTC), also known as Greenwich
Mean Time (GMT).  In areas which observe Daylight Savings Time during part of
the year, the local time of zone mail hour will change because InterSports does
not observe Daylight Savings Time. The exact timing of Zone Mail Hour is set
for each zone by the Zone Coordinator.

In InterSports Zone 102 and Zone 103, Zone Mail Hour is observed from 0900 to
1000 UTC.  In each of the time zones, this is:

     Eastern Standard Time          4 AM to 5 AM
     Central Standard Time          3 AM to 4 AM
     Mountain Standard Time         2 AM to 3 AM
     Pacific Standard Time          1 AM to 2 AM
     Hawaii Standard Time          11 PM to Midnight

─] Contacts [──────────────────────────────────────────────────────────(9-2)-

Canadian Zone Co-Ordinator - Patrick McCoy - 102:102/0
USA Zone Co-Ordinator ------ Jeff Binkley -- 103:103/0

─] Acknowledgements [──────────────────────────────────────────────────(9-3)─

As in any network, there are main founders... in this section, I'd like to
thank the following "founders" of InterSports <in no specific order>:

Timothy Lang, Norman So, Jim Burtt, Tom Forsberg, Hardy Rosenke, and many more!